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IP over IEEE 802.16 Problem Statement and Goals 
Status of This Memo 


This memo provides information for the Internet community. It does 
not specify an Internet standard of any kind. Distribution of this 
memo is unlimited. 


Abstract 


This document specifies problems in running IP over IEEE 802.16 
networks by identifying specific gaps in the IEEE 802.16 Media Access 
Control (MAC) for IPv4 and IPv6 support. This document also provides 
an overview of IEEE 802.16 network characteristics and convergence 
sublayers. Common terminology used for the base guideline while 
defining the solution framework is also presented. 
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1. Introduction 


Broadband Wireless Access networks address the inadequacies of low 
bandwidth wireless communication for user requirements such as high 
quality data/voice service, fast mobility, wide coverage, etc. The 
IEEE 802.16 Working Group on Broadband Wireless Access Standards 
develops standards and recommended practices to support the 
development and deployment of broadband Wireless Metropolitan Area 
Networks [IEEE802.16]. 


Recently the WiMAX Forum, and in particular, its NWG (Network Working 
Group) is defining the IEEE 802.16 network architecture (e.g., IPv4, 
IPv6, Mobility, Interworking with different networks, AAA, etc.). 

The NWG is thus taking on work at layers above those defined by the 
IEEE 802 standards (typically limited to the physical and link-layers 
only). Similarly, WiBro (Wireless Broadband), a Korean effort, which 
focuses on the 2.3 GHz spectrum band, is also based on the IEEE 
802.16 specification [IEEE802.16]. 


IEEE 802.16 [IEEE802.16] is point-to-point and connection-oriented at 
the MAC, physically arranged in a point-to-multipoint structure with 
the Base Station (BS) terminating one end of each connection and an 
individual Subscriber Station (SS) terminating the other end of each 
connection. The IEEE 802.16 convergence sublayer (CS) is at the 
uppermost part of the MAC that is responsible for assigning transmit- 
direction Service Data Units (originating from a higher layer 
application, e.g., IP or Ethernet at the BS or SS) to a specific 
outbound transport connection. IEEE 802.16 defines two convergence 
sublayer types, the ATM Convergence Sublayer (CS) and the Packet CS. 
The IP Specific Subpart (IP CS) and the 802.3 Ethernet Specific 
Subpart (Ethernet CS) of Packet CS are within the current scope of 
IETF efforts. 


There is complexity in configuring the IP Subnet over IEEE 802.16 
network because of its point-to-point connection-oriented feature and 
the existence of IP CS and Ethernet CS, which assume different 
higher-layer functionality. An IP Subnet is a topological area that 
uses the same IP address prefix where that prefix is not further 
subdivided except into individual addresses as specified in 
[RFC4903]. The IP Subnet configuration is dependent on the 
underlying link-layer’s characteristic and decides the overall IP 
operation on the network. The IP CS and Ethernet CS of IEEE 802.16 
assume different higher layer capabilities: IP routing functionality 
in the case of IP CS and bridging functionality in the case of 
Ethernet CS. This means that the link-layer’s characteristics 
beneath IP can change according to the adopted convergence sublayers. 
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This document provides the feasible IP Subnet model for each IP CS 
and Ethernet CS and specifies the problems in running IP for each 
case. This document also presents an overview of IEEE 802.16 network 
characteristics specifically focusing on the convergence sublayers 
and the common terminology to be used for the base guideline while 
defining solution frameworks. 


2. Terminology 


Subscriber Station (SS): An end-user equipment that provides 
connectivity to the IEEE 802.16 networks. It can be either fixed/ 
nomadic or mobile equipment. In mobile environment, SS represents 
the Mobile Subscriber Station (MS) introduced in [IEEE802.16e]. 


Base Station (BS): A generalized equipment set that provides 
connectivity, management, and control between the subscriber station 
and the IEEE 802.16 networks. 


Access Router (AR): An entity that performs an IP routing function to 
provide IP connectivity for the subscriber station (SS or MS). 


Protocol Data Unit (PDU): This refers to the data format passed from 
the lower edge of the MAC to the PHY, which typically contains SDU 
data after fragmentation/packing, encryption, etc. 


Service Data Unit (SDU): This refers to the data format passed to the 
upper edge of the MAC 


IP Subnet: Topological area that uses the same IP address prefix 
where that prefix is not further subdivided except into individual 
addresses as specified from [RFC4903]. 


Link: Topological area bounded by routers, which decrement the IPv4 
TTL or IPv6 Hop Limit when forwarding the packet as specified from 
[RFC4903]. 


Transport Connection: The MAC layer connection in IEEE 802.16 between 
an SS (MS) and BS with a specific Quality of Service (QoS) 
attributes. Several types of connections are defined and these 
include broadcast, unicast, and multicast. Each transport connection 
is uniquely identified by a 16-bit connection identifier (CID). A 
transport connection is a unique connection intended for user 
traffic. The scope of the transport connection is between the SS 

(MS) and the BS. 


Connection Identifier (CID): A 16-bit value that identifies a 
connection to equivalent peers in the IEEE 802.16 MAC of the SS (MS) 
and BS. 
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Ethernet CS: The 802.3/Ethernet CS specific part of the Packet CS 
defined in [IEEE802.16]. 


T 


802.1Q CS: The 802.1Q (VLAN) specific part of the Packet CS defined 
in [IEEE802.16]. 


IP CS: The IP specific subpart of the Packet CS defined in 
[IEEE802.16]. 


IPv4 CS: The IP specific subpart of the Packet CS, Classifier 1 
(Packet, IPv4) 


IPv6 CS: The IP specific subpart of the Packet CS, Classifier 2 
(Packet, IPv6). 


3. Overview of the IEEE 802.16 MAC Layer 


IEEE 802.16 [IEEE802.16] is point-to-point and connection-oriented at 
the MAC, physically arranged in a point-to-multipoint structure with 
the BS terminating one end of each connection and an individual SS 
terminating the other end of each connection. Each SS in the network 
possesses a 48-bit MAC address. The BS possesses a 48-bit unique 
identifier called "BSId". The BS and SS learn each others’ MAC 
Address/BSId during the SS’s entry into the network. Additionally, 
the BS may possess a 48-bit MAC address, but this is only known to 
the SS if using the Ethernet CS. 


3.1. Transport Connections 


User data traffic in both the BS-bound (uplink) and SS-—bound 
(downlink) directions is carried on unidirectional "transport 
connections". Each transport connection has a particular set of 
associated parameters indicating characteristics such as 
cryptographic suite and quality of service. 


After successful entry of an SS to the IEEE 802.16 network, no data 
traffic is possible as there are no transport connections between the 
BS and the SS yet. Transport connections are established by a 
3-message signaling sequence within the MAC layer (usually initiated 
by the BS). 


A downlink-direction transport connection is regarded as "multicast" 


if it has been made available (via MAC signaling) to more than one 
SS. Uplink-direction connections are always unicast. 
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B23: IEEE 802.16 PDU Format 


An IEEE 802.16 PDU (i.e., the format that is transmitted over the 
airlink) consists of a Generic MAC header, various optional 
subheaders, and a data payload. 


The IEEE 802.16 Generic MAC header carries the Connection Identifier 
(CID) of the connection with which the PDU is associated. We should 
observe that there is no source or destination address present in the 
raw IEEE 802.16 MAC header. 


3.3. IEEE 802.16 Convergence Sublayer 


The IEEE 802.16 convergence sublayer (CS) is the component of the MAC 
that is responsible for mapping between the MAC service and the 
internal connection oriented service of the MAC CPS (Common Part 
Sublayer), through classification and encapsulation. The 
classification process assigns transmit-direction Service Data Units 
(originating from a higher layer application, e.g., an IP stack at 
the BS or SS) to a specific outbound transport connection. The 
convergence sublayer maintains an ordered "classifier table". Each 
entry in the classifier table includes a classifier and a target CID. 
A classifier, in turn, consists of a conjunction of one or more 
subclassifiers -- where each subclassifier specifies a packet field 
(e.g., the destination MAC address in an Ethernet frame, or the Type 
of Service (TOS) field of an IP datagram contained in an Ethernet 
frame) together with a particular value or range of values for the 
field. To perform classification on an outbound Service Data Unit, 
the convergence sublayer proceeds from the first entry of the 
classifier table to the last, and evaluates the fields of the Service 
Data Unit for a match with the table entry’s classifier. When a 
match is found, the convergence sublayer associates the Service Data 
Unit with the target CID (for eventual transmission), and the 
remainder of the IEEE 802.16 MAC and PHY processing can take place. 


IEEE 802.16 defines two convergence sublayer types, the ATM CS and 
the Packet CS. The ATM CS supports ATM directly. The Packet CS is 
subdivided into three specific subparts. 


o "The IP Specific Subpart" carries IP packets over a point-to-point 
connection. 
o "The 802.3 Ethernet Specific Subpart" carries packets encoded in 


the 802.3/Ethernet packet format with 802.3 style headers. 


o "The 802.10 VLAN Specific Subpart" carries 802 style packets that 
contain 802.10 VLAN Tags. 


Jee, et al. Informational [Page 5] 


RFC 5154 IP over 802.16 PS and Goals April 2008 


4. 


4. 


Classifiers applied to connections at the time of connection 
establishment further classify and subdivide the nature of the 
traffic over a connection. 


The classifications that apply to the Ethernet CS include packet over 
the 802.3/Ethernet CS, IPv4 over the 802.3/Ethernet CS, IPv6 over the 
802.3/Ethernet CS, 802.3/Ethernet CS with RObust Header Compression 
(ROHC) header compression and 802.3/Ethernet with Enhanced Compressed 
Real-Time Protocol (ECRTP) header compression. 


The classifications that apply to the 802.1Q/VLAN CS include IPv4 
over 802.1Q/VLAN and IPv6 over 802.10/VLAN. 


It should be noted that while the 802.3/Ethernet CS has a packet 
classification that does not restrict the IP version (packet over the 
802.3/Ethernet CS), the IP CS and 802.1Q/VLAN CS do. All the IP 
classifiers for those CSs are either IPv4 or IPv6. 


The classifiers enable the MAC to be sure of the presence of fields 
in the headers and so to be able to apply the payload header 
suppression (PHS) feature of IEEE 802.16 to those headers. 


For the sake of brevity in this document, the following naming 
conventions will be used for particular classifications of particular 
subparts of particular CSs. 


Oo IPv4 CS: Packet CS, IP Specific Subpart, Classifier 1 (Packet, 
IPv4) 


o IPv6 CS: Packet CS, IP Specific Subpart, Classifier 2 (Packet, 
IPv6) 


o Ethernet CS: Packet CS, 802.3/Ethernet Subpart, Classifier 3 
(Packet, 802.3/Ethernet) 


An implementation of IEEE 802.16 can support multiple CS types. 
We can observe that the CS type, subpart, and classification actually 


defines the type of data interface (e.g., IPv4/IPv6 or 802.3) that is 
presented by IEEE 802.16 to the higher layer application. 


IP over IEEE 802.16 Problem Statement and Goals 
1. Root Problem 
The key issue when deploying IP over IEEE 802.16 networks is how to 


configure an IP Subnet over that link, which is connection-oriented 
and point-to-point in the MAC level. IP Subnet is a topological area 
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that uses the same IP address prefix where that prefix is not further 
subdivided except into individual addresses. [RFC4903] There are 
three different IP Subnet models [RFC4968] that are possible for IEEE 
802.16 network: 


1) Point-to-point Link Model 
2) Ethernet-like Link Model 
3) Shared IPv6 Prefix Link Model 


The specific problems and issues when adopting the above IP Subnet 
models to the IEEE 802.16 network are as below: 


In the point-to-point link model, each SS under a BS resides on a 
different IP Subnet. Therefore, only a certain SS and an AR exist 
under an IP Subnet, and IP packets with destination address of link 
local scope are delivered only within the point-to-point link between 
a SS and an AR. PPP [RFC1661] has been widely used for this kind of 
point-to-point link. However, the direct use of PPP is not possible 
on the IEEE 802.16 network because IEEE 802.16 does not define a 
convergence sublayer, which can encapsulate and decapsulate PPP 
frames. Therefore, there needs to be a mechanism to provide a point- 
to-point link between an SS and an AR in case of IP CS. The other 
alternative is to utilize PPP over Ethernet by using the Ethernet CS. 
However, Ethernet CS assumes the upper layer’s bridging functionality 
to realize the Ethernet-like link model. 


In the Ethernet-like link model, all SSs under an AR reside on the 
same IP Subnet. This also applies when SSs are connected with 
different BSs. This Ethernet-like link model assumes that underlying 
link-layer provides the equivalent functionality like Ethernet, for 
example, native broadcast and multicast. It seems feasible to apply 
IEEE 802.16’s Ethernet CS to configure this link model. However, 
IEEE 802.16’s MAC feature is still connection-oriented, and does not 
provide multicast and broadcast connection for IP packet transfer. 
Therefore, we need a mechanism like IEEE 802.1D to realize multicast 
and broadcast. Moreover, frequent IP multicast and broadcast 
signaling should be avoided so as not to wake up the SSs that are in 
sleep/idle mode [IEEE802.16e]. 


The shared IPv6 prefix link model eventually results in multi-link 


subnet problems [RFC4903]. In IEEE 802.16, the BS assigns separate 
TEEE 802.16 connections for SSs. Therefore, SSs are placed on 
different links. In this situation, distributing shared IPv6 prefix 


for SSs, which are placed on different links causes multi-link subnet 
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problems. This applies to IP CS and even to Ethernet CS if no 
bridging functionality is implemented on top of the BS or between the 
BS and the AR. 


We identified the feasible IP Subnet models for IEEE 802.16 networks 
depending on the convergence sublayers. At the current stage, only 
the IP CS and Ethernet CS of IEEE 802.16 are within the scope of 
ongoing IETF work. Following are the feasible IP Subnet models for 
each convergence sublayer used. 


1. Point-to-Point Link model for IP CS. 
2. Ethernet-like Link Model for Ethernet CS. 
According to the point-to-point feature of the IEEE 802.16 MAC, the 


Point-to-Point link model is the feasible IP Subnet model in the case 
of IP CS. For the Ethernet CS, the Ethernet-like link model is the 


feasible IP Subnet model. However, in this model unnecessary 
multicast and broadcast packets within an IP Subnet should be 
minimized. 


4.2. Point-to-Point Link Model for IP CS: Problems 
- Address Resolution: 


Address Resolution is the process by which IP nodes determine the 
link-layer address of a destination node on the same IP Subnet given 
only the destination’s IP address. In the case of IP CS, the IEEE 
802.16 MAC address is not used as part of the IEEE 802.16 frame so 
typical usage of the Address Resolution Protocol (ARP) or Neighbor 
cache does not apply. Thus, performing the address resolution may be 
redundant in the case of IP CS. For IPv4, ARP cannot be carried by 
the IP CS, so is not used either by the SS or by the BS. For IPv6, 
address resolution is the function of IP layer, and IP reachability 
state is maintained through neighbor discovery packets. Therefore, 
blocking neighbor discovery packets would break the neighbor 
unreachability detection model. 


- Router Discovery: 
The BS needs to send the Router Advertisement (RA) with separate IP 


prefix in unicast manner for each SS explicitly to send periodic 
router advertisements in IEEE 802.16 Networks. 
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- Prefix Assignment: 

Separate IP prefix should be distributed for each SS to locate them 
on different IP Subnets. When an SS moves between BSs under the same 
AR, the AR needs to redistribute the same IP Subnet prefix, which the 
SS used at the previous BS. 


—- Next-Hop: 


SS’s next-hop always needs to be the AR that provides the IP 
connectivity at that access network. 


- Neighbor Unreachability Detection (NUD): 

Because the SS always sees an AR as the next hop, the NUD is required 
only for that AR. Also the requirement of NUD may depend on the 
existence of a connection to the BS for that particular destination. 
- Address Autoconfiguration: 

Because a unique prefix is assigned to each SS, the IP Subnet 
consists of only one SS and an AR. Therefore, duplicate address 


detection (DAD) is trivial. 


4.3. Ethernet-Like Link Model for Ethernet CS: Problems 


- Address Resolution: 


For Ethernet CS, the sender needs to perform an address resolution to 
fill the destination Ethernet address field even though that address 
is not used for transmitting an IEEE 802.16 frame on the air. That 
Ethernet destination address is used for a BS or bridge to decide 
where to forward that Ethernet frame after decapsulating the IEEE 
802.16 frame. When the destination’s IP address has the same address 
prefix with its own, the sender should set the Ethernet frame’s 
destination address as the destination itself. To acquire that 
address, the address resolution should be performed throughout 
conventional broadcast- and multicast-based ARP or Neighbor Discovery 
Protocol (NDP). However, if not filtered (e.g., [RFC4541]), these 
multicast and broadcast packets result in the problem of waking up 
the SSs that are in sleep/idle mode [IEEE802.16e]. 


- Router Discovery: 
All SSs under the AR are located in the same broadcast domain in the 


Ethernet-like link model. In this environment, sending periodic 
Router Advertisements with the destination of all-nodes multicast 


Jee, et al. Informational [Page 9] 


RFC 5154 IP over 802.16 PS and Goals April 2008 


address results in the problem of waking up the SSs that are in 
sleep/idle mode [IEEE802.16e]. 


- Prefix Assignment: 


Because the same IP prefix is shared with multiple SSs, an IP Subnet 
consists of multiple SSs and an AR. The SS assumes that there exist 
on-link neighbors and tries to resolve the L2 address for the on-link 
prefixes. However, direct communication using link-layer address 
between two SSs is not possible with Ethernet CS alone; bridging 
functionality must be added on top of the BS or between the BS and 
AR. 


—- Next-Hop: 

When Ethernet CS is used and the accompanying Ethernet capability 
emulation is implemented, the next-hop for the destination IP with 
the same global prefix with the sender or link local address type 
should be the destination itself not an AR. 

- Neighbor Unreachability Detection (NUD): 


All SSs under the same AR are all the neighbors. Therefore, the NUD 
is required for all the SSs and AR. 


- Address Autoconfiguration: 
Duplicate Address Detection (DAD) should be performed among multiple 
SSs and an AR, which use the same IP prefix. The previous multicast- 
based DAD causes the problem of waking up the SSs that are in sleep/ 
idle mode [IEEE802.16e]. 

4.4. IP over IEEE 802.16 Goals 


The following are the goals in no particular order that point at 
relevant work to be done in IETF. 


Goal #1. Define the way to provide the point-to-point link model for 
IP CS. 


Goal #2. Reduce the power consumption caused by waking up sleep/idle 
[IEEE802.16e] terminals for Ethernet-like link model. 


Goal #3. Avoid multi-link subnet problems. 


Goal #4. Allow applicability of security schemes such as SEcure 
Neighbor Discovery (SEND) [RFC3971]. 
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Goal #5. Do not introduce any new security threats. 

Goal #6. Review management requirements and specifically the 
interfaces and specific management model (objects) for IP 
over IEEE 802.16 in collaboration with IEEE 802.16 working 
group. 

5. Security Considerations 

This documents describes the problem statement and goals for IP over 

IEEE 802.16 networks and does not introduce any new security threats. 

The IEEE 802.16 link-layer employs cryptographic security mechanisms 

as specified in [IEEE802.16] [IEEE802.16e]. 
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